Closes #428

This is a bit of a band-aide fix that disabled index scans if the table already has normal filters pushed down. I think its generally expected that the index scan would be way more selective, but as we don't have the chance to swap in the index scan until after normal filters are already pushed down we can't really apply it instead.

I made a quick attempt at trying to reconstruct and "pull up" the filters from the table scan again but it seems like it would be very fragile and error prone to do correctly 100% of the time, especially for more advanced queries. It's also a bit silly as we'd basically undo a lot of the work that went into pushing down the table filters to begin with and have to replace basically the whole logical get node.

The proper solution would be to improve the index interface in DuckDB core to give custom indexes a chance to properly participate in the query planning process while filters are being evaluated for pushdown. We could then also look at stats/estimated cardinalities to decide whether or not to use an index scan or not, instead of just always matching specific predicates.

We now pull up the filters from the table scan before replacing it with an index scan, ensuring index scans are applied even if other filters are present as well. This is usually the right thing to do as geometry predicates are usually much more expensive to evaluate compared to other filters that DuckDB can push down.